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(54) IP packet access gateway 

(57) An IP Packet Access Gateway (IP PAG) system 
manages an IP bearer path between communicating IP 
endpoints. The system includes an IP PAG having a first 
IP bearer connection termination for terminating a first 
bearer connection with a first IP endpoint, and a second 
IP connection termination for terminating a second bear- 
er connection with a second IP endpoint. A call control 



entity is associated with the IP PAG and communicates 
call control instructions thereto. The call control instruc- 
tions include instructions for logically concatenating the 
connections into an active IP bearer path extending be- 
tween the first IP endpoint and the second IP endpoint. 
A bearer traffic IP packet handler in the IP PAG moves 
bearer traffic IP packet pay loads over the active IP bear- 
er path. 
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Description 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

[0001] This invention relates to telecommunication 
networks. More particularly, the invention concerns the 
control of voice calls in an IP network. 

2. Description of the Prior Art 

[0002] By way of background, IP (Internet Protocol) 
packet networks are now being used to provide bearer 
pathways for voice communications. In these systems, 
voice calls between communicating IP endpoints, such 
as IP telephones, are placed on through-connections 
established by network switching nodes. Such connec- 
tions are router-based and are generally under the con- 
trol of the endpoints themselves. 
[0003] What is lacking in conventional VoIP (Voice 
over IP) systems is an interface for implementing bearer 
path connection control and manipulation at packet net- 
work points of entry. In particular, there is no mechanism 
for positive enforcement of bearer connection establish- 
ment and teardown. Connections cannot be terminated 
except by one or both of the IP endpoints. This means 
that parties using IP telephones might continue to talk 
even though billing for a call has stopped (i.e., because 
bearer path remains open). Conversely, billing might 
continue after the parties have ended the call. 
[0004] Conventional Vol P systems also lack ability to 
provide pivot points for VoIP lines and trunks carrying 
IP bearer traffic into and out of an IP core network. Such 
pivot points are currently only provided by LAGs (Line 
Access Gateways) and TAGs (Trunk Access Gateways) 
that carry purely TDM bearer traffic or which interwork 
between TDM bearer traffic and packet oriented (e.g., 
ATM, IP) bearer traffic. Without pivot points on the trunk 
side of an IP network entry point, packet switches need 
to be aware of when another switch in a call manipulates 
the bearer path. The bearer path thereby becomes a 
shared resource that all switches will jointly use to pro- 
vide their own services. This greatly increases the com- 
plexity of implementing services because feature inter- 
actions cross switch boundaries. Without pivot points on 
the line side of an I P network entry point, packet switch- 
es cannot perform call redirection and insert/remove 
service circuits in established connections to provide the 
usual services available to TDM (Time Division Multi- 
plexing) lines. Such services include N-way bridging, 
announcement playback, tone generation, tone detec- 
tion, speech recognition, and multicasting. 
[0005] In addition to the foregoing disadvantages of 
conventional VoIP systems, certain law enforcement 
statutes, such as the Communications Assistance for 
Law Enforcement Act (CALEA) (47 U.S.C. 1001 et 
seq.), require that a call involving a surveillance subject 



remain under surveillance even after the subject is no 
longer a participant in the call. Because court orders for 
CALEA surveillance may limit the geographic scope 
over which the surveillance may be performed, there is 

5 a need to ensure that the bearer path for a call stays 
within the geographic bounds within which it may be sur- 
veyed. If I P endpoints are able to establish a bearer path 
using conventional routing, there is no such guarantee. 
[0006] Accordingly, there is a need in a packet net- 

10 work providing voice connection service for an interface 
system that implements bearer path connection control 
and manipulation at packet network points of entry. The 
same capability is also needed when data and video 
calls are transported over IP 

15 

SUMMARY OF THE INVENTION 

[0007] The foregoing problems are solved and an ad- 
vance in the art is obtained by an IP Packet Access 

20 Gateway (IP PAG) system for managing an IP bearer 
path between communicating IP endpoints. The system 
includes an IP PAG having a first IP bearer connection 
termination forterminating a first bearer connection with 
a first I P endpoint, and a second I P connection termina- 
ls tion for terminating a second bearer connection with a 
second IP endpoint. A call control entity is associated 
with the IP PAG and communicates call control instruc- 
tions thereto. The call control instructions include in- 
structions for logically concatenating the connections in- 

30 to an active IP bearer path extending between the first 
IP endpoint and the second IP endpoint. A bearer traffic 
IP packet handler in the IP PAG moves bearer traffic IP 
packet payloads over the active IP bearer path. 
[0008] In preferred embodiments of the invention, the 

35 |p PAG includes a bearer connection address table that 
associates the active IP bearer path with the first bearer 
connection andthesecond bearerconnection in accord- 
ance with the above-mentioned concatenating instruc- 
tions. The connection address table includes a key entry 

40 corresponding to the active IP bearer path (IP bearer 
path entry). This key entry comprises first and second 
tuples respectively corresponding to the first bearer con- 
nection and the second bearer connection. The first tu- 
ple includes an IP address and port number for the IP 
PAG and an IP address and port number for the first IP 
endpoint. The second tuple includes an IP address and 
port number for the IP PAG and an IP address and port 
number for the second IP endpoint. 
[0009] As stated, the bearer traffic IP packet handler 

so is adapted to move bearer traffic IP packet payloads 
from a source IP endpoint to a destination IP endpoint. 
In the preferred embodiments of the invention, it does 
this by (1) receiving a bearer traffic IP packet from the 
source IP endpoint over a source bearerconnection, (2) 

55 searching for an IP bearer path entry in the connection 
address table having an associated first tuple that con- 
tains the packet header source IP address and source 
port number of the received I P packet, (3) upon locating 
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the IP bearer path entry in the connection address table, 
determining from the second tuple associated with the 
entry the IP address and port number of the destination 
I P endpoint, (4) rewriting the packet header of the bearer 
traffic IP packet using the IP address and port number 
of the IP PAG as the source IP address and source port 
number, and using the IP address and port number of 
the destination IP endpoint as the destination IP address 
and destination port number, and (5) sending the rewrit- 
ten bearer traffic IP packet to the destination IP endpoint 
over a destination bearer connection. 
[0010] The bearer traffic IP packet handler may also 
be adapted to perform bearer traffic policing to verify that 
the received bearer traffic IP packet is authorized for 
transmission on that path and is associated with an ac- 
tive IP bearer path. To that end, each IP bearer path 
entry in the address connection table preferably in- 
cludes a status flag that is indicative of an associated 
IP bearer path being active or inactive. The bearer traffic 
policing function will then include checking whether the 
packet is received from a connection presented in the 
bearer connection address table and whether the con- 
nection is active. Unauthorized packets and packets 
sent over an authorized but inactive IP bearer path can 
be logged and/or dropped. In addition, bearer traffic po- 
licing could include enforcement of the amount of IP 
bearer traffic the source is allowed to send for a given 
IP bearer path. 

[0011] The IP PAG can be controlled by the call con- 
trol entity to act as an IP bearer path pivot point, so that, 
by way of example, service circuits can be switched in 
and out of a call. To implement such a pivot point, the 
call control entity modifies the connection address table 
to add an IP bearer path for each required connection. 
This will typically result in multiple table entries compris- 
ing tuples that correspond a common IP endpoint. Piv- 
oting is then performed by selectively activating the sta- 
tus flags associated with each IP bearer path entry. 
[0012] The IP PAG system of the invention may fur- 
ther include a signaling traffic IP packet handler for re- 
laying signaling messages from an IP endpoint to a des- 
tination. The signaling traffic IP packet handler main- 
tains an IP endpoint address table that lists IP address- 
es for IP endpoints that are authorized to send signaling 
messages to the destination. The table also lists port 
numbers, one for each authorized IP endpoint, to be 
used by the IP PAG as the source port number when 
the signaling traffic IP packet handler relays the signal- 
ing message to the call control entity or an SNMP man- 
ager. The call control entity or SNMP manager can then 
use the source port number in the received signaling 
packet to identify the original sender (IP endpoint) of the 
signaling message. Signaling message relay can in- 
clude receiving a signaling traffic IP packet from an IP 
endpoint and rewriting the packet header by (1) setting 
the source IP address to the IP address of the relaying 
IP PAG : (2) setting the source port number to the port 
number assigned to the IP endpoint originating the sig- 



naling message (as found in the IP endpoint address 
table), (3) setting the destination IP address to the IP 
address of the destination (as determined by the desti- 
nation port number and source IP address of the sign- 

s aling message received), and (4) leaving the destination 
port unchanged. The signaling message could be an H. 
323, SIP, H.248, or other signaling message intended 
for a call control entity, an SNMP signaling message in- 
tended for an SNMP manager, or otherwise. 

w [0013] The signaling traffic IP packet handler may al- 
so be adapted to perform signaling traffic policing to ver- 
ify that the IP endpoint sending a signaling message is 
authorized to send the message. The signaling traffic 
policing function can include performing a table lookup 

'5 jn the IP endpoint address table relative to an IP signal- 
ing packet received from an IP endpoint to verify that 
the IP endpoint is listed in said table, and to find the IP 
PAG port number assigned to the IP endpoint stored in 
said table. As an additional feature, the IP PAG can be 

20 adapted to dynamically throttle signaling messages sent 
to the call control entity. 

[0014] In an embodiment of the invention that can be 
used in association with a network switching node, the 
IP PAG system includes a line-side IP PAG terminating 

25 plural IP lines and a trunk-side IP PAG terminating plural 
IP trunks. An IP switching fabric interconnects the line- 
side IP PAG and the trunk-side IP PAG. The system may 
further include one or more resource servers, interwork- 
ing gateways, interworking units, or data termination 

30 systems. 

BRIEF DESCRIPTION OF THE DRAWING 

[0015] The foregoing and other features and advan- 
35 tages of the invention will be apparent from the following 
more particular description of preferred embodiments of 
the invention, as illustrated in the accompanying Draw- 
ing, in which: 

40 Fig. 1 is a block diagram showing an IP Packet Ac- 
cess Gateway (IP PAG) system constructed in ac- 
cordance with the invention; 
Fig. 2 is a diagrammatic illustration of a bearer con- 
nection address table generated in accordance with 

45 the invention; 

Fig. 3 is a block diagram showing an IP PAG and 
the modification of IP packets routed through the IP 
PAG from a first IP endpoint to a second IP end- 
point; 

so Fig. 4 is a diagrammatic illustration of an IP endpoint 
address table: 

Fig. 5 is a block diagram showing another IP PAG 
system associated with a network switching node; 
Fig. 6 is a block diagram showing a VoIP network 
55 incorporating IP PAGs in accordance with the inven- 
tion; and 

Fig. 7 is a flow diagram showing an exemplary call 
setup performed in the IP PAG system of Fig. 6. 
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DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

[001 6J Turning now to the Drawing, wherein like ref- 
erence numbers indicate like elements in all of the sev- 
eral views ; Fig. 1 illustrates an IP PAG system 2 for man- 
aging an IP bearerpath between communicating IP end- 
points. The system 2 includes an IP PAG 4 having a first 
IP bearer connection termination 6 for terminating a first 
bearer connection 8 with a first IP endpoint 10. The IP 
PAG 4 further includes a second IP connection termina- 
tion 12 for terminating a second bearer connection 14 
with a second IP endpoint 16. A call control entity 18 is 
associated with the IP PAG 4 and communicates call 
control instructions thereto. The call control instructions 
include instructions for logically concatenating the first 
and second bearer connections 8 and 14 (as shown at 
20) into an active IP bearer path 22 extending between 
the first IP endpoint 10 and the second IP endpoint 16. 
A bearer traffic IPpacket handler 24 (bearer traffic pack- 
et handler) in the IP PAG 4 moves bearer traffic IP pack- 
et payloads over the active IP bearerpath 22. In the en- 
suing discussion, it will be assumed that the IP end- 
points 10 and 16 are adapted for VoIP calls. As such, 
the active IP bearer path 22 will be hereinafter referred 
to as an active VoIP bearer path. 
[0017] In preferred embodiments of the invention, the 
IP PAG 4 includes a bearer connection address table 26 
that is created and dynamically managed by the call 
control entity 1 8 in accordance with the above-men- 
tioned concatenating instructions. This table associates 
the active VoIP bearer path 22 with the first bearer con- 
nection 8 and the second bearer connection 14. As 
shown in Fig. 2, the bearer connection address table 26 
will typically include an array of key entries 28 that cor- 
respond to various VoIP bearer paths (Vol P bearer path 
entries) being handled by the IP PAG 4 under instruc- 
tions from the call control entity 18, Each VoIP bearer 
path entry 28 contains transport addresses 30 and 32 
for the two bearer connections associated with the rep- 
resented VoIP bearer path. These transport addresses 
can be represented as IP tuples that each contain the 
IP addresses and port numbers associated with a bear- 
er connection between an IP endpoint and the IP PAG 
4. In particular each tuple will include an IP address and 
port number used by the I P endpoint relative to the bear- 
er connection and an IP address and port number used 
by the IP PAG relative to the bearer connection. 
[001 8] By way of example, the bearer connection ad- 
dress table 26 includes a VoIP bearer path entry 34 that 
represents the active VoIP bearer path 22. Associated 
with the entry 34 is a first tuple 36 corresponding to the 
first bearer connection 8 and a second tuple 38 corre- 
sponding to the second bearer connection 14. The first 
tuple 36 includes an IP address/port number pair for the 
first IP endpoint 1 0 : and an IP address/port number pair 
for the IP PAG 4. The second tuple 38 includes an IP 
address/port number pair for the second endpoint 16, 



and an IP address/port number pair for the IP PAG 4. 
The bearer traffic packet handler 24 moves bearer traffic 
I P packet payloads between the first I P endpoint 1 0 and 
the second I P endpoint 1 6 by looking for the entry 34 in 

5 the bearer connection address table 26. For example, 
when the bearer traffic packet handler 24 receives a 
bearer traffic IP packet from the first IP endpoint 10 over 
the first bearer connection 8, it uses the packet header 
information to search for the first tuple 36. Insofar as the 

10 first tuple 36 contains the IP address/port number used 
by the first IP endpoint 1 0 relative to the first bearer con- 
nection 8, and an IP address/port number used by the 
IP PAG 4 relative to the first bearer connection 8 : this 
information will match the source and destination ad- 

15 dress information in the incoming packet header. 

[0019] If the first IP endpoint 10 is involved in a con- 
ference call, or has received a tone or announcement, 
or has otherwise communicated with an entity otherthan 
the second IP endpoint 16, the bearer connection ad- 

20 dress table 26 may contain multiple VoIP bearer path 
entries 34 having an associated tuple 36 identifying the 
first IP endpoint. In that case : the IP PAG 4 can be con- 
trolled by the call control entity 1 8 to act as a Vol P bearer 
path pivot point by selectively activating status flags 40 

25 associated with the VoIP bearerpath entries. One such 
status flag, referenced at 42 in Fig. 2, is associated with 
the VoIP bearer path entry 34. 

[0020] Thus ; upon locating the first tuple 36 in the 
bearer connection address table, the bearertrafficpack- 

30 et handler 24 checks the status flag 42 of the entry. If 
the status flag 42 is inactive, the bearer traffic packet 
handler 24 continues to search the bearer connection 
address table for an entry with a matched tuple 36 and 
an active status flag. If the status flag 42 is active, it then 

35 determines from the second tuple 38 the IP address and 
port number of the second IP endpoint 1 6. As indicated, 
the second tuple contains an IP address and port 
number used by the IP PAG 4 relative to the second 
bearer connection 14, and an IP address and port 

40 number used by the second IP endpoint 16 relative to 
the second bearer connection 14. The bearer traffic 
packet handler 24 then rewrites the packet header of 
the incoming IP packet using information determined 
from the second tuple 38, and sends the rewritten IP 
packet to the second IP endpoint 16 over the second 
bearer connection 14. Fig. 3 illustrates this packet trans- 
formation process. A packet header for a packet re- 
ceived at the IP PAG 4 from the IP endpoint 10 is shown 
at 44. Trie packet header of the transformed packet sent 

50 to the IP endpoint 16 is shown at 46. 

[0021 ] The bearer traffic packet handler 24 may also 
be adapted to perform bearer traffic policing including 
enforcement of the amount of I P bearer traffic the source 
is allowed to send for a given IP bearer path. Actions 

55 taken as a result of bearer traffic policing may include 
logging and/or dropping unauthorized packets. 
[0022] The IP PAG 4 may further include a signaling 
traffic IP packet handler 46 (signaling traffic packet han- 
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dler) for relaying signaling messages from one or both 
of the IP endpoints 10 and 16 to a destination. As shown 
in Fig. 4. the signaling packet traffic handler 46 main- 
tains an authorized IP endpoint address table 48 that 
includes one entry 50 per IP endpoint that is authorized 5 
to send signaling messages to the destination. This ta- 
ble can be statically provisioned using a subscriber da- 
tabase, or could be dynamically provisioned if dynamic 
IP endpoint registration is supported. Each entry 50 in- 
cludes the IP address 52 of an authorized IP endpoint 
and a corresponding IP PAG signaling port number 54. 
As part of signaling message relay, a signaling traffic IP 
packet is received at the IP PAG 4 from an IP endpoint 
and the packet header is rewritten. In particular, the 
source IP address is changed to the IP address of the 
IP PAG 4 and the source port number is changed to the 
assigned IP port number found in the IP endpoint ad- 
dress table 48. The destination IP address is then 
changed to the IP address of the destination, and the 
destination IP port number is changed to the IP Port 
number of the destination. The signaling message could 
be an H.323, SIP (Session Initiation Protocol), H.248, 
or other signaling message sent to a call control entity, 
an SNMP (Simple Network Management Protocol) sig- 
naling message sentto an SNMP manager (see below), 
or otherwise. 

[0023] The signaling traffic packet handler 46 prefer- 
ably performs signaling traffic policing to verify that an 
IP endpoint sending signaling messages is authorized 
to send such messages. The signaling traffic policing 
function includes performing a table lookup in the au- 
thorized IP endpoint address table 48 relative to a sig- 
naling traffic IP packet received at the IP PAG 4. The 
purpose of this lookup is to verify that the IP address of 
the IP endpoint is listed in the authorized IP endpoint 
address table 48 and to find the port number assigned 
to the IP endpoint. As stated, the port number found in 
the IP endpoint address table will be used as the source 
port number in the signaling message to be relayed to 
its final destination. As an additional feature, the IP PAG 
4 could, based on a request from the call control entity 
1 8, throttle signaling messages destined to the call con- 
trol entity. This throttling could be of all signaling mes- 
sages or could be selective based on IP endpoint. 
[0024] The IP PAG 4 can be implemented as a pro- 
grammed computer platform equipped with (at least) 
two network ports (e.g., Ethernet ports) that provide the 
bearer connection terminations 6 and 12, and a signal- 
ing port terminating the communication link 1 9 to the call 
control entity 18. The IP PAG4 can (and normally will) 
have a different IP address for the two network ports. 
The selected computer platform will provide a program- 
mable execution environment for implementing the 
bearer traffic packet handler 24 and the signaling traffic 
packet handler 46 as software processes. A random ac- 
cess memory space (not shown) will be provided to 
maintain the tables 26 and 48. 

[0025] The call control entity 18 communicates with 



8 

the IP PAG 4 using a media gateway control protocol 
such as IPDC (IP Device Control) or H.248 (also known 
as the Media Gateway Control (Megaco) Protocol). Both 
of these protocols are well known in the art, but exten- 
sions will be required to support the IP-PAG functions 
described herein. The call control entity 18 may be im- 
plemented on a separate computer platform from the IP 
PAG 4, or on the same platform. 
[0026] Turning now to Fig. 5, an embodiment of the 
invention is shown for use in association with a network 
switching node 60. In this embodiment, an IP PAG sys- 
tem 62 includes a line-side IP PAG 64 terminating an IP 
line 66 to an IP telephone 68. The IP PAG system 62 
further includes a trunk-side IP PAG 70 terminating a 
BICC (Bearer Independent Call Control) supported IP 
packet trunk 72 that connects to an IP core network 74. 
An IP switching fabric 76 is disposed between the line- 
side IP PAG 64 and the trunk-side IP PAG 70. The line- 
side IP PAG 64 connects to the IP switching fabric 76 
through a communication pathway 78. The trunk-side 
IP PAG 70 connects to the IP switching fabric 76 through 
a communication pathway 80. The switching node 60 
further includes one or more resource servers, inter- 
working gateways, interworking units, or data termina- 
tion systems. These communication support entities are 
collectively referenced at 82 in Fig. 5. A communication 
pathway 84 connects the communication support enti- 
ties 82 to the IP switching fabric 76. 
[0027] The call control entity of the IP PAG system 62 
is referenced at 86 in Fig. 5. It communicates with the 
IP PAGs 64 and 70 using the IPDC or H.248 protocol. 
A communication pathway 88 connects the call control 
entity 86 to the IP switching fabric 76. An SNMP man- 
ager 90 is also provided. It connects to the IP switching 
fabric 76 through a communication pathway 92. 
[0028] The line-side IP PAG 64 supports line-side traf- 
fic from the IP telephone 68 and, together with the call 
control entity 86, performs the IP PAG functions de- 
scribed above relative to Figs. 1-4. These functions in- 
clude per call control of bearer paths between the IP tel- 
ephone 68 and remote or local IP endpoints, bearer traf- 
fic policing, signaling message relay, and signaling traf- 
fic policing. Note that bearer traffic may be carried on a 
bearer path that connects the IP telephone 68, the IP 
switching fabric 76 ; the trunk-sided IP PAG 70 and a re- 
mote IP endpoint (not shown) communicating with the 
IP core network 74. This bearer path includes the con- 
nections labeled 94, 96 and 98 in Fig. 5. Alternatively, 
bearer traffic may be carried on a bearer path that con- 
nects the IPtelephone68,the IP switching fabric 76 and 
one of the communication support entities 82, such as 
a resource server that provides tones and announce- 
ments to the IP telephone 68 ; and/or detects tones or 
recognizes speech generated from the I P telephone 68. 
This bearer path includes the connections labeled 94 
and 100 in Fig. 5. 

[0029] The above-described bearer paths illustrate 
that the line-side IP PAG 64 can act as a bearer traffic 
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pivot point that supports call redirection and the inser- 
tion/removal of service circuits in established connec- 
tions. Features such as conferencing, call transfer, call 
waiting, multiple call appearances, shared DN (Dialed 
Number), and call pickup can thus be supported. More 
particularly, the line-side IP PAG 68 can be used to sup- 
port functions such as (1 ) bearer-hold-and-altemate, (2) 
bearer-move, (3) bearer bridging, (4) dial tone, (5) stut- 
ter dial tone, (6) reorder tone, (7) call waiting tone : (8) 
digit collection/flash detection, (9) audible ringing to- 
ward the IP telephone 68 for incoming calls, and (10) 
comfort noise toward the I P telephone 68 when a bearer 
path is placed on hold. Wiretapping support is also pro- 
vided due to the ability keep bearer connections routed 
through the fixed location of the line-side IP PAG 64. 
[0030] Signaling traffic relayed by the line-side IP 
PAG 64 may include SNMP messages, H.323 messag- 
es, SIP messages, H.248 messages etc., depending on 
the signaling protocol(s) supported by the IP telephone 
68. Message relay can also be used for IP telephone 
provisioning, including dynamically updating the author- 
ized IP endpoint table 48. Using a port number assign- 
ment scheme, the line-side IP PAG 64 can be configured 
to relay SNMP messages to the SNMP manager 90, as 
shown by the connections labeled 102 and 104 in Fig. 
5. Similariy : H.323, SIP, or H.248 messages can be re- 
layed to the call control entity 86, as shown by the con- 
nections labeled 106 and 108. 

[0031] The trunk-side IP PAG 70 supports trunk-side 
traffic from the IP core network 74 and performs the 
functions of per-call control of bearer paths and bearer 
traffic policing. The trunk-side IP PAG 70 provides bear- 
er path connections between remote IP endpoints (not 
shown) communicating over the IP packet trunk 72 and 
local IP endpoints in the network switching node 60, in- 
cluding the line-side IP PAG 64 and one or more of the 
communication support entities referenced at 82. In Fig. 
5, the bearer path formed by the connections labeled 96 
and 98 represents one such example in which the trunk- 
side IP PAG 70 maintains a connection to the line-side 
IP PAG 64. The bearer path formed by the connections 
labeled 98 and 110 represents another example where- 
in the trunk-side IP PAG 70 maintains a connection to 
one of the communication support entities 82. Like the 
line-side IP PAG 68, the trunk-side IP PAG 70 also pro- 
vides bearer pivot points and can be used to perform 
such functions as generating tones toward the IP core 
network 74 for incoming calls, generating comfort noise 
toward the IP core network when a bearer path is placed 
on hold, and collecting digits carried over the bearer 
path. 

[0032] The call control entity 86 controls the handling 
of bearer traffic routed through the IP PAGs 64 and 70 
in the manner described above relative to Figs. 1 -3. The 
connection labeled 112 in Fig. 5 carries IDPC or H.248 
messages from the call control entity 86 to the line-side 
IP PAG 68. The connection labeled 114 in Fig. Scarries 
IDPC or H.248 messages from the call control entity 86 



to the trunk-side IP PAG 70. 

[0033] Turning now to Figs. 6 and 7, an exemplary call 
set-up procedure wilt be described for a BICC call in- 
volving IP PAGs. In Fig. 6. a VoIP communication sys- 

5 tern 1 20 includes a call originating IP switching node 122 
and a call terminating IP switching node 124. An inter- 
vening IP core network 126 carries bearer traffic be- 
tween the IP switching nodes 122 and 124. An SS7 sig- 
naling network 1 28 carries BICC messages between the 

10 IP switching nodes 122 and 124. 

[0034] The originating IP switching node 122 includes 
an originating Access Gateway (AG1 ) 1 30 that provides 
a user-to-network interface for an originating IP end- 
point (not shown), which is assumed to originate a VoIP 

15 call. The gateway 1 30 can be implemented as a LAG, a 
TAG. or a line-side IP PAG as described above relative 
to Fig. 5. The originating IP switching node 122 further 
includes an originating trunk-side IP PAG 132, an orig- 
inating call control entity 134 and an IP switching fabric 

20 136. The terminating IP switching node 124 includes a 
terminating Access Gateway (AG2) 1 40 that provides a 
user-to-network interface for a terminating IP endpoint 
(not shown) that is assumed to terminate the VoIP call 
from the originating IP endpoint. Like the originating 

25 gateway 130, the terminating gateway 140 can be im- 
plemented as a LAG, a TAG, or a line-side IP PAG as 
described above relative to Fig. 5. The terminating IP 

1 switching node 124 further includes a terminating trunk- 
side IP PAG 142, a call control entity 144 and an IP 

30 switching fabric 146. A bearer path between the origi- 
nating gateway 130 and the terminating gateway 140 is 
formed by three bearer connections respectively la- 
beled 1 50 ; 1 52 and 1 54. A signaling connection 1 56 ex- 
tends between the call control entities 134 and 144. 

35 [0035] It is assumed for purposes of the present ex- 
ample that the call control entities 134 and 144 are 
adapted to communicate connection control messages 
to IP PAGs under their dominion using the H.248 proto- 
col. As is known, the H.248 protocol enables media 

40 gateways to establish connection terminations and to 
group such terminations within "contexts" that allow the 
routing of bearer traffic between the connections that 
are represented therein. 

[0036] Fig. 7 shows the message flow during call set- 
45 up in the VoIP communication system 120. The mes- 
sages include IPDC signaling messages respectively 
exchanged between the gateways 130 and 140 and the 
call control entities 134 and 144, BICC signaling mes- 
sages exchanged between the call control entities 134 
so and 144. and H.248 control messages exchanged be- 
tween the call control entities 134 and 144 and their re- 
spective IP PAGs 132 and 142. 
[0037] In step 1 , the originating AG 130 sends an IP- 
DC connection request message (RCCP) to the origi- 
55 nating call control entity 134 ; and the originating call 
control entity returns an IPDC message (ACCP) ac- 
knowledging receipt of the RCCP request. Note that the 
connection request message will include a port number 
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(AGWolP) that the originating gateway 130 intends to 
use for the connection. In step 2, the originating call con- 
trol entity 134 sends an H.248 message (Add(term1, 
AG1VolP)/Add(term2)) to the originating trunk-side IP 
PAG 1 32. This message requests the originating trunk- 5 
side IP PAG 132 to add a pair of connection termina- 
tions, one (terml) for a connection to the originating 
gateway 1 30 (at its port number AG1 VoIP) and the other 
(term2) for a connection to the terminating trunk-side 
IP-PAG 142. In step 3, the originating trunk-side IP PAG 10 
132 sends an H.248 reply message (AddAck 
(PAG1VolP1)/AddAck(PAG1VolP2)) back to the origi- 
nating call control entity 134 acknowledging that it has 
established the two requested first and second termina- 
tions and advising that they will be respectively handled *5 
by its port numbers PAG1VolP1 and PAG1 VolP2. 
[0038] In step 4a, the originating call control entity 1 34 
sends an IPDC message (RMCP) to the originating 
gateway 130 advising of the remote RTP port number 
(PAG1 VolP1) for the bearer connection. In step 4b, the 20 
originating call control entity 134 sends a BICC Initial 
Address Message (BICC:IAM(PAG1 VolP2)) to the ter- 
minating call control entity 144 advising that the origi- 
nating trunk-side IP PAG 132 is ready to terminate a 
connection with the terminating trunk-side IP PAG 142 25 
at the former's port number PAG1 VolP2. 
[0039] In step 5a, the originating gateway 130 returns 
an IPDC message (AMCP) to the originating call control 
entity 134 acknowledging receipt of the RMCP mes- 
sage. In step 5b, the terminating call control entity 144 
sends an H.248 message (Add(term1 . PAG1VolP2)/ 
Add(term2)) to the terminating trunk-side IP PAG 1 42 to 
add a pair of connection terminations, one for a connec- 
tion to the originating trunk-side IP PAG 132 at its port 
number PAG1VolP2 and the other for a connection to 
the terminating gateway 140. In step 6. the terminating 
trunk-side IP PAG 142 sends an H.248 reply message 
(AddAck(PAG2VolP1)/AddAck(PAG2VolP2)) back to 
the terminating call control entity 144 acknowledging 
that it has established the two requested terminations 
and advising that the first termination will be handled by 
its port number PAG2VolP1 and the second termination 
will be handled by its port number PAG2VolP2. 
[0040] In step 7a, the terminating call control entity 
144 sends a BICC message (BICC:APM(PAG2VolP1) 
to the originating call control entity 1 34 advising that the 
terminating trunk-side IP PAG 142 is ready to terminate 
a connection to the originating trunk-side IP PAG 1 32 at 
the former's port number PAG2VolP1. In step 7b. the 
terminating call control entity 144 sends an IPDC con- 
nection request message (RCCP) to the terminating 
gateway 140 specifying the RTP port number 
(PAG2VolP2) the terminating trunk-side IP PAG allo- 
cates for the connection, and the terminating gateway 
returns an acknowledgement message (ACCP). Note 
that this acknowledgement message will contain a port 
number (AG2Vol P) that the terminating gateway 1 40 in- 
tends to use for the connection. 



[0041 ] In step 8a, the originating call control entity 1 34 
sends an H.248 message (Modify(term2.PAG2VolP1)) 
to the originating trunk-side IP PAG 1 32 requesting that 
it set the remote RTP port number for its second termi- 
nation to port number PAG2VolP1 returned by the ter- 
minating trunk-side IP PAG2 in step 6. In step 8b, the 
terminating call control entity 144 sends an H.248 mes- 
sage (Modify(term2,AG2VolP)) to the terminating trunk- 
side IP PAG 142 requesting that it set the remote RTP 
port number for its second termination to port number 
AG2VoiP returned by the terminating gateway 140 in 
step 7b. In step 9a ; originating trunk-side IP PAG 132 
sends an H.248 reply message (ModifyAck) to the orig- 
inating call control entity 134 acknowledging that it has 
updated its second termination, and then cuts through 
the connection between the two terminations. In step 9b, 
the terminating trunk-side IP PAG 142 sends a similar 
message (ModifyAck) to the terminating call control en- 
tity 144, and then cuts through the connection. 
[0042] In step 1 0, the originating call control entity 1 34 
sends a BICC message (BICC:APM) to the terminating 
call control entity 144 to acknowledge receipt of the 
BICC:APM message sent in step 7a. In step 11 , the ter- 
minating call control entity sends a BICC message 
(BICC:ACM) to the originating call control entity. In step 
12, an IPDC notify message (NCAS) is sent from the 
terminating gateway 140 to the terminating call control 
entity 144 informing the called party has answered the 
call. In step 13, the terminating call control entity sends 
a BICC message (BICC:ANM) to the originating call 
control entity 1 34. At this point the bearer path is estab- 
lished and ready for bearer traffic. 
[0043] Accordingly, an IP Packet Access Gateway (IP 
PAG) system has been disclosed for managing a VoIP 
bearer path between IP endpoints. Advantageously, by 
serving as a point of connection mediation, the dis- 
closed IP PAG system provides per-call control of IP 
bearer paths independently of the actions of the com- 
municating endpoints. 3earertraffic policing is also pro- 
vided, thereby implementing a form of firewall protection 
that can be enforced dynamically on a per-call basis. 
When implemented in a VoIP communication network, 
the IP PAG system of the invention provides feature in- 
dependence by allowing each switching node to imple- 
ment calling features independently of features being 
implemented at other switching nodes. Without the IP 
PAG system, activation of call feature requests from IP 
endpoints would require cooperation between the 
switching nodes involved in a call. Because each switch- 
ing node operates independently of the other there 
would be a possibility of simultaneous and conflicting 
feature requests being implemented. The IP PAG sys- 
tem of the invention eliminates the possibility of such 
conflicts as well as the need for negotiation when acti- 
vating feature requests. Support for communications 
assistance for law enforcement is also provided by vir- 
tue of the fact that a bearer path can be held within a 
geographic boundary in which it may be surveilled. By 
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comparison, in VoIP calls handled by traditional routers, 
there is no such guarantee of geographic control. 
[0044] While various embodiments of the invention 
have been described, it should be apparent that many 
variations and alternative embodiments could be imple- 
mented in accordance with the invention. In addition to 
Voice over IP calls there will be data and video over IP 
calls and this invention would also apply to these calls. 
It is understood, therefore, that the invention is not to be 
in any way limited except in accordance with the ap- 
pended claims, 



Claims 

1 . A method for managing an IP bearer path between 
IP endpoints, comprising the steps of: 

terminating a first IP bearer connection with a 
first IP endpoint; 

terminating a second bearer connection with a 
second IP endpoint; 

logically concatenating said connections into 
an active IP bearer path extending between 
said first IP endpoint and said second IP end- 
point; and 

moving bearer traffic IP packet payloads over 
said active IP bearer path, said packet pay- 
loads comprising voice, data, multimedia or 
other information. 

2. A method in accordance with Claim 1 : wherein said 
concatenating step comprises establishing a key 
entry in a bearer connection address table that as- 
sociates said active IP bearer path with said first 
bearer connection and said second bearer connec- 
tion. 

3. A method in accordance with Claim 2 ; wherein said 
key entry corresponds to said active IP bearer path 
(IP bearer path entry) and comprises first and sec- 
ond tuples respectively corresponding to said first 
bearer connection and said second bearer connec- 
tion. 

4. A method in accordance with Claim 3 .wherein said 
first tuple includes a first IP address and a port 
number for said IP PAG and an IP address and a 
port number for said first IP endpoint, and said sec- 
ond tuple includes a second IP address and a port 
number for said IP PAG and an IP address and a 
port number for said second IP endpoint. 

5. A method in accordance with Claim 4, wherein said 
moving step includes moving bearer traffic IP pack- 
et payloads from said first IP endpoint to said sec- 
ond IP endpoint by: 



receiving a bearer traffic IP packet from said 
first IP endpoint over said first bearer connec- 
tion; 

searching for an IP bearer path entry in said 
5 connection address table having an associated 

first tuple that contains the packet header 

source IP address and source port number of 

said received IP packet; 

upon locating said IP bearer path entry in said 
w connection address table, determining from the 

second tuple associated with said entry the IP 

address and port number of said second IP 

endpoint; 

rewriting the packet header of said bearer traffic 
15 IP packet using an IP address and a port 

n umber associated with said active bearer path 
as the source IP address and source port 
number, and using the IP address and port 
number of said second IP endpoint as the des- 
20 tination IP address and destination port 

number; and 

sending said rewritten bearer traffic IP packet 
to said second IP endpoint over said second 
bearer connection. 

25 

6. A method in accordance with Claim 5, further in- 
cluding performing bearer traffic policing to verify 
that said received bearer traffic IP packet is associ- 
ated with an active IP bearer path and is authorized 

30 for transmission on that path. 

7. A method in accordance with Claim 6 ,wherein each 
VoIP bearer path entry in said address connection 
table includes a status flag indicative of an associ- 

35 ated IP bearer path being active or inactive, and 
wherein said bearer traffic policing step includes 
checking said status flag for active status. 

8. A method in accordance with Claim 7, wherein said 
40 bearer traffic policing includes logging and/or drop- 
ping unauthorized packets. 

9. A method in accordance with Claim 7, wherein said 
connection address table contains multiple IP bear- 

45 er path entries having associated tuples identifying 
said first IP endpoint, and wherein a bearer path piv- 
ot point is implemented by selectively activating the 
status flags associated with said IP bearer path en- 
tries. 

50 

10. A method in accordance with any of the preceding 
claims further including relaying signaling messag- 
es from one or both of said IP endpoints to a desti- 
nation. 

55 
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